related to #2775

Rationale for this change

This PR aligns the AlwaysTrue and AlwaysFalse expression serialization to use the boolean primitives true/false instead of string representation, matching the Iceberg ExpressionParser.

I know the spec defines the true/false expressions as string but today we can't hit the scan planning client endpoint following these models.

I know the spec defines the true/false expressions as a string representation, but currently we can't successfully use the scan planning client endpoint with those models. Java's actual implementation serializes these as boolean literals.

For instance, with what we have today we would throw an illegal argument exception:

{
    "snapshot-id": 2540284336700708540,
    "filter": "true",
    "case-sensitive": true
}

Throws: java.lang.IllegalArgumentException: argument "content" is null

But, this works just fine (notice no quotes):

{
    "snapshot-id": 2540284336700708540,
    "filter": true,
    "case-sensitive": true
}

Are these changes tested?

Yes

Are there any user-facing changes?

No, this only affects the JSON serialization format to match Java Cores behavior.